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ABSTRACT 

NASA’s Morpheus Project has developed and tested a prototype planetary lander 
capable of vertical takeoff and landing that is designed to serve as a testbed for advanced 
spacecraft technologies. The lander vehicle, propelled by a LOX/Methane engine and sized 
to carry a 500kg payload to the lunar surface, provides a platform for bringing technologies 
from the laboratory into an integrated flight system at relatively low cost. From the 
beginning, one of goals for the Morpheus Project was to streamline agency processes and 
practices. The Morpheus project accepted a challenge to tailor the traditional NASA systems 
engineering approach in a way that would be appropriate for a lower cost, rapid prototype 
engineering effort, but retain the essence of the guiding principles. The team has produced 
innovative ways to create an infrastructure and approach that would challenge existing 
systems engineering processes while still enabling successful implementation of the current 
Morpheus Project. This paper describes the tailored systems engineering approach for the 
Morpheus project, including the processes, tools, and amount of rigor employed over the 
project’s multiple lifecycles since the project began in FY11. Lessons learned from these 
trials have the potential to be scaled up and improve efficiency on a larger projects or 
programs. 


1. Introduction 


NASA’s strategic goal of extending human activities across the solar system requires an integrated architecture 
to conduct human space exploration missions beyond low earth orbit (LEO). This architecture must include 
advanced, robust in-space transit and landing vehicles capable of supporting a variety of lunar, asteroid and 
planetary missions; automated hazard detection and avoidance technologies that reduce risk to crews, landers and 
precursor robotic payloads; and in-situ resource utilization (ISRU) to support crews during extended stays on 
extraterrestrial surfaces and provide for their safe return to earth. The Morpheus Project provides an integrated 
vertical test bed (VTB) platform for advancing multiple subsystem technologies, and for evolving these technologies 
into capable systems that can be demonstrated and tested. 

The Morpheus vehicle’s LOX/methane propulsion system is one of two key technologies that Morpheus is 
designed to integrate and demonstrate. The Morpheus LOX/methane propulsion system can provide a specific 
impulse during space flight of up to 321 seconds; it is clean-burning, non-toxic, and cryogenic, but space- storable. 
Additionally, for future space missions the methane could be produced in situ on Mars, and the oxygen is 
compatible on-board with life support systems and power generation. These attributes make LOX/methane an 
attractive propulsion technology for a lander of this scale. 

ALHAT, the primary Morpheus payload, provides the second key technology: autonomous landing and hazard 
avoidance. When landing autonomously on any planetary or other surface, the vehicle must be able to identify a safe 
landing site that is free of large boulders, rocks, craters, or highly sloping surfaces. Morpheus is designed to carry 
ALHAT sensors and software supporting tests that will demonstrate an integrated vehicle capability to perform these 
tasks. 

Morpheus design and development began in June 2010, primarily by an in-house team at NASA’s Johnson Space 
Center. In addition to the development and demonstration of integrated technologies for human spaceflight, one of 
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the primary objectives of Morpheus is to explore lean development, streamline project processes and approaches, 
and look at innovative ways to execute that could be scaled up to a larger NASA project or program. This paper 
describes the tailored systems engineering and integration approach for the Morpheus project, including the 
processes, tools, and amount of rigor employed over the project’s multiple lifecycles from 2010 to 2013. 

2. System description 


The VTB system elements include the flight test vehicle, ground systems, and operations. This section provides a 
description of each, in order to provide context for the scope of the systems engineering and integration tasks. 

A. Vehicle 

Morpheus is a “quad” lander design with four tanks and a single engine. The primary structure consists of 
welded aluminum box beams, machined parts, and aluminum plate. The landing struts have honeycomb crush pads 
in the feet to attenuate landing loads. The propellant tanks are made of welded 5061 aluminum hemispheres. The 
avionics and GN&C components are located on a plate that spans the top deck of the primary structure. 

The propulsion system uses an impinging element-type engine design, with liquid oxygen and methane as the 
propellants. The engine is film-cooled and operates as a blow-down system producing up to 5000 lbf of thrust. Two 
orthogonal electromechanical actuators (EMAs) gimbal the engine to provide thrust vector control of lateral 
translation and pitch and yaw attitudes. Varying the main engine throttle setting provides vertical control of ascent 
and descent rates. Roll control is provided by small LOX/methane engines that produce up to 20 pounds of thrust 
each. Cold gas jets provide a backup roll control capability using the pressurized helium in the propellant tanks. 

The avionics and power subsystems include the flight computer, data recording, instrumentation, 
communications, cameras, and batteries. The flight computer is an AITech S900 CompactPCI board with a 
PowerPC 750 processor. Up to 16 GB of data can be stored on board. Data buses include RS-232, RS-422, Ethernet, 
and MIL-STD-1553. Multiple channels of analog and digital inputs are used for both operational and developmental 
flight instrumentation, including temperature sensors, pressure transducers, and tri-axial accelerometers. Wireless 
communications between ground operators and the vehicle use a spread spectrum frequency band. Multiple on- 
board cameras provide views of the vehicle during testing. Eight lithium polymer batteries provide vehicle power. 

The GN&C sensor suite includes a Javad Global Positioning System (GPS) receiver, an International Space 
Station (ISS) version of Honeywell’s Space Integrated GPS/INS (SIGI), a Systron Donner SDI-500 inertial 
measurement unit), and an Acuity laser altimeter. The vehicle is able to determine position to less than one meter, 
velocity to less than three cm/second, and attitude knowledge within 0.05 degrees. 

The vehicle software is architected around Goddard Space Flight Center’s (GSFC) Core Flight Software (CFS). 
GSFC designed CFS as a set of reusable software modules in a flexible framework that can be adapted to various 
space applications. Morpheus software developers built upon CFS by adding custom application code unique to the 
Morpheus vehicle and mission design. The vehicle flight software runs under the commercial VxWorks operating 
system, but the software development environment tool suite includes many open source applications such as 
Redmine and Subversion. 

Due to aggressive schedule and the test program nature of the Morpheus project, the software team searched for 
open source and off the shelf solutions to meet the system requirements. The solution selected was the open source 
Core Flight Executive (cFE) system. The Core Flight Executive is a portable, platform independent embedded 
system framework developed by NASA Goddard Space Flight Center (GSFC). This framework is used as the basis 
for the flight software for satellite data systems and instruments, but can be used on other embedded systems. The 
cFE is written in C and depends on another software library called the Operating System Abstraction Fayer (OSAF). 
Sitting on top of the cFE is the Core Flight Software library and application layer, which provides common 
spacecraft flight software applications that can configured and modified for specific missions. The CFS application 
model allows for rapid mission specific application development on top of the CFS layers. 

A complement to the cFE/CFS system is the Integrated Test and Operations System (ITOS). ITOS provides a 
fully capable test and ground system to quickly and easily interface with CFS flight software. 

The Morpheus vehicle is designed primarily as a single string vehicle. For example, there is only a single CPU, a 
single main engine, and a single command/telemetry radio. However, some components have redundant elements, 
such as the critical feedback sensors on the EMAs. Additionally, there are redundant downmode capabilities that 
have been implemented, including the ability to switch to a dissimilar backup IMU or means of roll control. The 
vehicle is designed with a path to space flight; the majority of components have a space equivalent of the terrestrial 
versions that are currently being used. 
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B. ALHAT Payload 

One of the primary objectives of the Morpheus project is to demonstrate and advance the Technology Readiness 
Level (TRL) of precision landing and hazard avoidance capabilities developed by the ALHAT system. The ALHAT 
project has been developing an integrated Autonomous Guidance, Navigation, and Control (AGNC) hardware and 
software system capable of detecting and avoiding surface hazards and autonomously guiding a manned or 
unmanned space vehicle to a safe touchdown within 90 meters of a pre-designated planetary or asteroid site. This 
payload project has been conducted with a team of technical experts from JSC, Draper Laboratory, Jet Propulsion 
Laboratory (JPL), Langley Research Center (LaRC), and the Applied Physics Laboratory at Johns Hopkins 
University. 

ALHAT is using an onboard laser altimeter and flash Light Detection and Ranging (LIDAR) for the onboard 
sensors to perform Terrain Relative Navigation (TRN) and Hazard Relative Navigation (HRN). A flash LIDAR 
flashes a very quick laser beam over a planetary surface area of approximately 100 x 100 meters. This cross-cutting 
technology has also being employed by commercial ISS supply companies and NASA’s Orion project for automated 
rendezvous and docking (AR&D). The photons emitted from the LIDAR strike the surface of the target object or 
surface and return to a timing detector grid, giving very precise range and bearing measurements for each photon 30 
times a second. These three dimensional measurements provide elevation information for each small segment of the 
surface, thus producing a digital elevation map that can be used to determine hazards to the landing vehicle. 
Software algorithms interpret this information and determine the safest regions to land without hazards. To avoid 
interference from surface dust while descending to a safe region, the ALHAT design supplements the flash LIDAR 
with a Doppler LIDAR velocimeter, an IMU, and software to ensure precise measurements of lander attitude, 
altitude, and velocity are available at all times during the final phases of landing. These surface relative 
measurements provide the onboard navigation system with sufficient accuracy during last 30 seconds of the descent 
phase to navigate to the chosen safe region regardless of any dust disturbed by the descent engine. 

In October 2012, ALHAT and Morpheus were combined as a single project. Since then, ALHAT has maintained 
their heritage systems engineering approach, but has integrated into the Morpheus systems engineering process as 
needed. 

C. Ground Systems 

The VTB flight complex (VFC) at the Johnson Space Center includes 20’ x 20’ concrete pads located on a 
section of the JSC antenna range near an old Apollo-era antenna tower. One of the concrete pads contains a flame 
trench to divert plume energy away from the vehicle during launch from the ground. 

About 2000 feet away is the Morpheus control center for on-site field testing at JSC, the small 2-story building 
18 that was formerly used for rooftop GPS testing and storage. The main upstairs room has a window that looks 
directly out onto the test area, making it highly suitable as the operations “front room,” configured with three rows 
of computer tables for operator workstations. An adjacent room serves as the “back room” for support personnel. 

The operator workstations use GSFC’s Integrated Test and Operations System (ITOS) ground software. Like 
CFS, ITOS was developed as ground control and display software for GSFC space vehicles and has been made 
available to other projects at NASA. ITOS is individually configured on each workstation to display vehicle 
telemetry and information unique to each operator position. 

During each test, the Morpheus Project streams mission telemetry, voice loops, and video from the testing 
control center to JSC’s Mission Control Center (MCC) over dedicated wireless and wired networks. From there, 
data and video can be made available to internal and external networks for NASA personnel and the general public. 

A thrust termination system (TTS) is employed both for range safety and independent test termination purposes. 
Closing either of two motorized valves in the TTS will shut off the flow of liquid oxygen and methane to the engine 
and terminate engine thrust. These TTS valves are completely independent from the rest of the vehicle systems and 
commanded using separate Ultra High Frequency (UHF) radios. The commands to initiate thrust termination are 
sent from a control unit located in the operations center during any live engine testing. 

Ground systems also include propulsion ground support equipment (GSE). The consumables required for an 
engine test include liquid oxygen, liquefied natural gas, helium, liquid nitrogen, and gaseous nitrogen. The power 
GSE is a portable ground power cart that is used to supply power to the vehicle until the test procedures call for a 
switch to internal vehicle power. The ground power cart uses heavy duty batteries and can provide up to 72 amp- 
hours of power for pre- and post-test activities. The mechanical GSE includes a rented crane for tethered or hot fire / 
hold-down testing. For tethered tests, an energy absorber is placed between the vehicle and the crane boom arm. The 
energy absorber is an aluminum piston and cylinder with cardboard honeycomb material that can attenuate up to 
10,000 lb. This load attenuation protects the vehicle and crane structures in the event engine thrust needs to be 
terminated prematurely, causing the vehicle to drop to the end of the tether. Ground systems also include a variety of 
transportation assets, provided primarily by JSC Center Operations. 
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For testing at Kennedy Space Center, the project uses the north end of the Shuttle Landing Facility. A 100m x 
1 00 m “hazard field” has been built with multiple concrete landing pads for flight testing in a simulated hazardous 
landing environment. KSC also provides the use of a mission operations facility, as well as an on-site vehicle hangar 
and storage for team assets, plus all of the other ground systems needed for flight test operations. 

D. Operations 

The final element of the Morpheus system is Operations. Nine primary operator positions are staffed by team 
members: test conductor (TC), operator (OPS), propulsion (PROP), avionics, power and software (APS), guidance, 
navigation and control (GNC), ground control (GC), range safety officer, and the flight manager (FM). During tests 
with payloads aboard, another position may be included, such as one for ALHAT. Each position is certified through 
specific training. 

Certification is also required for three pad crew (PAD) positions. PAD-1 is the pad crew leader, responsible for 
communicating directly with the test conductor during operations and ensuring each procedural step is executed at 
the pad. PAD-2 and PAD-3 provide support to PAD- 1 , and conduct all handling of cryogenic fluids and most other 
consumables. 

On test days, many other JSC and Morpheus team personnel serve in various functions. JSC riggers support 
vehicle transportation and crane operations. Support personnel for each subsystem monitor data or help out during 
testing in the “back room” of the control center. Other team members stand by for potential troubleshooting if 
problems arise. 


3. Morpheus Test Campaign 


Morpheus testing includes three major types of integrated tests: hot- fire, tether, and free-flight. 

A. Hot Fire Testing 

During hot-fire testing the vehicle is completely restrained from movement and the primary focus is to test the 
LOX/methane propulsion system. In this configuration a crane is used to suspend the vehicle above the ground to 
provide clearance for the vehicle exhaust plume. The vehicle is also constrained from below using straps anchored 

to the ground that prevent vertical and lateral vehicle motion. 

Figure 1 shows the vehicle during test in the hot-fire configuration. 
The vehicle is suspended approximately 20’ above a concrete pad by a 
crane outfitted with shielding to prevent damage from flames or debris 
during the test firing. Additional restraints are attached below the vehicle 
made of nylon overwrapped with fireproof insulation or chains. 

he objectives for hot- fire tests include demonstration of the igniter, 
engine ignition, performance at varied throttle settings and burn duration 
tests. The Morpheus project test approach limits testing on a dedicated 
engine test stand and emphasizes a quick transition to integrated vehicle 
tests. Testing on the vehicle promotes optimization of engine 
performance for the actual vehicle propulsion feed system instead of the 
test stand system. It also allows gimbal sweeps to evaluate the integrated 
performance of the actuators under load. The majority of engine 
characterization is conducted on the vehicle, essentially making the hot- 

fire configuration the primary engine test stand for the Morpheus Project. 

A variation on hot-fire testing is a ground hot fire test. Ground hot fire 
is conducted with the vehicle chained down directly over the launch area 
for very short (<3 sec) engine firings. This provides the team with 
characterization of the vibro-acoustic, thermal, and overpressure environments for the vehicle under launch 
conditions. 



Figure 1 - Morpheus in Hot- fire Test 
Configuration 
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Figure 2 - Morpheus 1.5 ‘Bravo’ executing a 
translational Tether Test in August 2013. Mars 
soil simulant was deployed on the launch pad 
to study plume impingement for the Mars 2020 
program. 


B. Tether Testing 

For tether tests the vehicle is suspended from a crane as 
shown in Figure 2 to enable testing of the propulsion and 
integrated GN&C without the risk of a vehicle departure or 
crash. The goal of these tests is typically to ascend 5’ 
vertically and hover in place for a pre-programmed duration. 
Upon successful completion of the hover, the vehicle 
descends and “lands” at the end of the tether. 

Due to the potential dynamic loads during tethered flight, 
a substantially larger 120-ton crane is used for this testing. 
An energy absorber in line with the tether reduces the loads 
on both the crane and Morpheus vehicle and helps prevent 
damage to either asset. 

Tether testing provides the first opportunity to perform 
integrated testing of the Morpheus vehicle with closed-loop 
GN&C. The primary objective of tether testing is to 
demonstrate 6 degree-of-freedom (DOF) GN&C for vertical 
translation, hover and simulated landing operations. An 
additional objective is to understand and rapidly refine the 
integrated performance of avionics, propulsion, and GN&C 
without risk of a vehicle crash. 


C. Free Flight Testing 

Morpheus “free-flights” demonstrate the fully integrated flight capability of the vehicle with no restraints. Free- 
flight safeguards are automatic on-board aborts, remotely commanded aborts, as well as the redundant and 
independent TTS that can be activated by spotters who visually determine trajectory deviations. The primary goal 
for Morpheus is to perform a Hazard Detection Phase (HDP) flight profile that will fully exercise the ALHAT 
components and software in a simulated planetary landing trajectory. A variety of free-flight trajectories will be 
flown to incrementally build up to the full HDP trajectory. 


4. Project Chronology 


Armadillo Aerospace worked with NASA to build the initial Morpheus 1.0 vehicle, and performed all of the 
structural welding, feed system integration, and tank development and qualification. The initial avionics were also 
provided by Armadillo. The Morpheus team had a nearly continuous presence at the Armadillo facility from the 
time that vehicle integration started. 

The initial Morpheus VTB 1.0 configuration was tested from April 2011 through August 2011. In late 2011 and 
early 2012, the team began upgrading the VTB to the Morpheus 1.5 configuration, including a higher performance 
HD4 engine, an improved avionics and power distribution design, the addition of LOX/methane thrusters for roll 
control, and the incorporation of the ALHAT sensors and software. The Morpheus 1.5 “alpha” (1.5A) vehicle 
performed over 26 flight tests before a loss of vehicle (LOV) event in August 2012. The project had pre-declared 
loss of vehicle to not be a mishap, and when the crash occurred, the team conducted its own internal failure 
investigation. The failure occurred due to loss of navigation data from the SIGI inertial measurement unit. The most 
likely cause of the failure was identified as component failure due to the high vibro-acoustic environment at vehicle 
liftoff. A number of corrective actions were implemented in response. 

The Morpheus 1.5 “bravo,” or 1.5B vehicle, was already in work as a spare vehicle when 1.5 A was lost. 
Although the 1.5B vehicle looks nearly identical to the 1.5A vehicle, the team took the opportunity to incorporate 
many upgrades to improve robustness and reliability, including addressing the contributing factors for the 1.5A loss 
of vehicle. Nine months later the 1.5B vehicle was ready to begin flight testing. To date, three hot fire tests and nine 
tether tests have been performed with the 1.5B vehicle at JSC. 
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5.0 Systems Engineering Approach 


In 2009 the majority of the civil servant workforce was employed by the Space Shuttle Program, the ISS 
Program, or the Constellation Program. The attributes of these, and most large NASA programs, include very large 
teams (>10,000 team members), are highly distributed geographically among NASA Centers and NASA contractors, 
have a Prime contractor and many sub-contractors, cost in the tens to hundreds of billions of dollars over the 
program life, and entail the high rigor associated with sending humans into space. 

When the Morpheus project was initiated in early 2010, the JSC Engineering Directorate recognized that, 
without a governing large program, the Morpheus team would have the opportunity to explore options for how to 
execute the project. In comparison to those larger human spaceflight projects, Morpheus would have a small in- 
house team (<50-100 team members), be primarily co-located at JSC, have no Prime contractor and only 
engineering support contractors or partners,, and would not need to be designed for crew safety. However, since 
Morpheus’s scope includes a flying vehicle, ground systems, and mission operations, there would be enough 
parallels to the larger programs that the team could experiment with approaches that could potentially be scaled back 
up. Furthermore, the team would gain a breadth and depth of design, development, and testing experience over a 
relatively short period of time. 

On the other end of the aerospace scale from the large NASA programs was Armadillo Aerospace. At the start of 
Morpheus, Armadillo was a small startup aerospace company located near Dallas founded by video game designer 
John Carmack. The total number of employees was less than 10, and they performed all design, development, 
testing, and operations for a series of vertical testbed vehicles for the purpose of participating in X-Prize challenges, 
and later, for suborbital rocket development. Armadillo had a staff of highly capable engineers and technicians, and 
the way that they operated as a small in-house team without any bureaucratic overhead was eye-opening for the 
NASA engineers. It created the opportunity to say “if Armadillo does it this way, why can’t we?” and to challenge 
what had become the typical NASA approach in many areas. 

The project was not required to show compliance with NASA Procedural Requirements (NPR) 7120.5, “NASA 
Space Flight Program and Project Management Handbook,” nor with NPR 7123.1, “System Engineering Procedural 
Requirements.” However, both documents were used as the basis for defining systems engineering products and 
processes from early on in the project. The project management guidance to SE&I, in order to hold the line on lean 
development, was that “all processes had to buy their way onto the project.” This meant that value had to be 
demonstrated for any effort or initiative that would take up team members’ (including SE&I team members) time. 
Furthermore, the tools and processes that the team would use would need to have a low learning curve and be easily 
used by the whole team. 

Recognizing the range of options for project execution, the project defined a “scale of rigor,” as illustrated in 
Figure 3. The X-axis of the graph shows some representative programs, projects, or organizations, while the Y-axis 
represents rigor in the form of configuration management, requirements development and flow down, safety 
reviews, decision board hierarchy, or any other number of mechanisms and processes used to add rigor, 
repeatability, redundancy or discipline into the execution of a spaceflight mission. 

There was little opportunity in recent decades to develop completely new human spaceflight systems until the 
Constellation Program was formulated. NASA has gone a generation since building a piloted spacecraft. Many of 
the best talent in the Agency have spent their entire careers in the sustaining or operational phase of the Shuttle and 
ISS Programs. Because of these factors it is difficult for our workforce to move toward the left of Figure 1. It 
actually helps to work with some of the aerospace startups, such as Armadillo, in order to see the other extreme and 
enable intelligent choices as to the “right” rigor for a development or prototype system. Ultimately however there is 
no formula for determining the “right” level of any of these attributes; it must be agreed on by the project leadership. 
“It is not about having process or not having process, it is about the right level of process at the right time”. 

It is important to note that, although there is no human crew for the Morpheus vehicle, the project has always 
placed the safety of personnel and the public as the highest priority. The highest levels of rigor employed on the 
project have been to ensure safe operations, including the handling of cryogenic fluids, pressurized systems, and 
safety in the event of a vehicle fire or crash. 
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Figure 3 - Project Scale of Rigor 


With regard to process rigor, these are the primary considerations: 

Content attributes: 

• Quantity: what is the extent to which relevant information exists for all aspects of the product, considering 
breadth and depth? 

• Quality: how high quality is the information - is it accurate, readable, concise, clear? 

• Availability: is the information available in written form to whomever needs it, and it is accessible? 

• Freshness: how current is the information? 

• Review: has the information been reviewed, scrutinized or approved by other knowledgeable personnel 
besides the author? 

Process attributes: 

• Process definition: is there a process in place that the team members know to follow for information 
management, including changes, and to what extent / under which circumstances it needs to be followed? 

• Advocacy: Is compliance with the process supported and advocated by the management team? 

• Controls: is there a means in place to monitor the process compliance? 

With regard to technical rigor, these are the primary considerations: 

• How fully will the design be vetted with other knowledgeable experts? 

• How fully will the integrated system impacts of the design be evaluated? 

• What is acceptable to the project in terms of factors of safety and design margin? 

• What will the project accept with regard to pedigree of the procured or in-house built hardware? 

• How much technical insight and oversight is acceptable for the software and hardware designs and 
implementation? 

• What level of qualification testing is appropriate? Which items need to undergo qualification testing? Will 
any qualification testing include testing to failure? 

• How much verification testing is required to enable mission success? And how much analysis? 

In August 2010, the Morpheus SE&I team held a half-day SE&I retreat. The participants included all of the 
SE&I team and most of the subsystem leads. As show in Figure 4, the “scale of rigor” was drawn on the whiteboard 
with a list of typical SE&I products down the left-hand side. A red line was drawn just to indicate the middle of the 
scale, from research and development (R&D) on the left side to human spaceflight (HSF) on the right side. 
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Participants were asked to plot their initials 
somewhere on the scale of where they think we 
should be for Morpheus, which was back then 
known as Risk Reduction 2 (RR-2). 

The rectangular boxes were drawn on the 
whiteboard to encompass the majority of the team 
members’ initials, with the exception of some 
outliers that were on the far ends of the scale. It can 
be seen that the team members were fairly evenly 
split on the appropriate level of rigor for most of 
the products listed, with the exception of a bias to 
have less data management, and more test planning 
and preparation. Since team members’ opinions on 
how much rigor is called for on Morpheus spanned 
a wide range between R&D and Human Space 
Flight, this kept us in a daily tension. For any given 
decision, many team members would think it was 
not enough, and others would think it was too 
much. For this reason, management advocacy and 
buy-in was critical. 

From the beginning, the Morpheus 
“management team” consisted of the project 
manager, the deputy project managers (initially 
there were two, one for business and one technical), 
the SE&I Lead, and the Chief Engineer. This 

organizational structure has been critical to effective SE&I execution, because it allows direct project management 
buy-in before rolling out a task or product expectation for the team. 

The project has a very flat organizational structure that is different from the Work Breakdown Structure. The 
project WBS reflects a fairly typical multi-tiered structure, with the top tier aligned with the space flight project 
WBS from NPR 7120.5. The team organizational structure, however, is much more flat. The subsystem leads report 
directly to the management team. Figure 5 shows the project’s work breakdown structure. 
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Figure 5 - Project Work Breakdown Structure 

The SE&I team is responsible for the traditional systems engineering products over the course of the project 
lifecycle, but the responsibility for technical integration is shared by the subsystem leads. The composition and 
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focus of the SE&I team has changed over the three years on the project, but at the peak, there have been less than ten 
individuals serving in various SE&I roles. On average, the team is made up of about 6 engineers that are working 
mostly full-time on Morpheus. 

One of the most crucial SE&I roles is that of Vehicle Manager (VM). In 2010 when the Morpheus team was 
working closely with Armadillo at their facility near Dallas, it became clear that the best way to ensure good 
integration was to have a “man on the scene” as much of the time as possible. This helped facilitate communication, 
but also removed some of the burden of documentation from Armadillo engineers, who were unaccustomed to many 
of the NASA documentation expectations. The project continued this approach by having the VM present in the 
vehicle hangar during all development and testing activities. In 2012, the role was expanded to include two vehicle 
managers that shared responsibilities, and in 2013 the role expanded to three individuals. All three have desks in the 
hangar and trade off responsibilities for being the vehicle “gate keeper.” Nearly all vehicle work is arranged through 
the VM. It is the VM’s responsibility to determine when a requested task needs management insight or approval, or 
to coordinate with other team members if it is an integrated activity. 

A lesson learned early in the project is the difficulty that engineers have in serving a “part-time” SE&I role when 
splitting time between Morpheus and a completely different project. Because the Morpheus SE&I team is very 
“boots on the ground,” and the team focus is on face-to-face interactions, there is an expectation that SE&I team 
members be present and engaged with the team in order to serve in an integration role and to be technically 
knowledgeable such that they can help the subsystems rather than primarily soliciting documentation from them. For 
that reason, a “half-time” SE&I team member is generally only able to be engaged in attending and supporting 
activities or performing SE&I tasks, but not both, compromising both that individual’s productivity and personal 
feeling of contribution. 

The project meeting rhythm has also changed over time. Early in the project, there were more structured 
integration meetings that were planned to cover specific subsystems and integrated technical topics. The need for 
these meetings waxed and waned over the project lifecycle. Since the Morpheus 1.5B project lifecycle began in 
September 2012, the project has fared well with daily 9 am “standup tagups,” which take place in the vehicle 
hangar. Typically a few team members dial in by telecon, but most of the subsystem leads are present in the hangar, 
and the meetings is conducted using task lists on the whiteboard. There is more opportunity for team members to be 
engaged when they do not have their laptops open to be distracted. Targeted technical meetings are set up when 
needed, but more often in the B220 conference room or standing around the vehicle. This dynamic helps keep the 
team present and focused. 

The only formal meeting that has persisted since the beginning of the project is the Morpheus Review and 
Control Board (MRCB). The MRCB is scheduled to be held once a week, and is the forum used for formal project- 
level decisions. At the MRCB, the project also reviews calendar, schedule, and technical statuses or other topics. 

An important contributing factor for the team’s use of limited meetings and limited documentation is the project 
manager’s technical engagement in the project. When a PM is present for the majority of technical discussions, his 
or her insight and understanding allows faster decision making with less need for team members to produce a 
“change package” prior to discussion. The SE&I team works to capture change rationale and ensure that design 
documentation is updated accordingly, but technical engagement by the PM ensures that the project decisions are 
well-informed and made quickly. 

From many perspectives, the systems engineer is the person who levies the processes, procedures, controls, and 
paperwork that most discipline-oriented engineers consider to be a hindrance rather than a help. However, there is an 
equally important view of the systems engineer as responsible for the technical integrity of the end products, not just 
the processes. This latter role is often filled by a typical “Chief Engineer” role, who, as a systems engineer, is 
responsible for deep and broad technical insight and oversight. The Morpheus experience highlights the value of 
having a technically knowledgeable systems engineering team. Having a systems engineer who does not have a solid 
grasp of the technical domains is like having a dragon that cannot breathe fire; it may look like a dragon, and act like 
a dragon, but it will not be very useful in battle. 

In his I AC paper “How Do We Fix System Engineering, 1 ’’former NASA Administrator Mike Griffin writes: “In 
a word, system engineering is not fundamentally about “process”, except in cases where such process is clearly 
lacking, a state which characterizes very few large scale projects today. System engineering is about something 
more.” In his conclusion he goes on to explain that “properly understood, the core purpose of the discipline of 
system engineering, and the primary responsibility of the system engineer, is the fielding of an elegant design. As 
discussed here, an elegant design is one which produces the intended result, is both robust and efficient, and 
generates a minimum of unintended consequences.” The message from Griffin’s paper is not that process isn’t 
important; it is expected to be executed. However, a project will not succeed on process alone; an “elegant design” 
will dictate the success of the systems engineering effort. Systems engineering teams need to stay aware of the 
technical implications of all aspects, and not assume that executing all processes will result in success. 
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The next section describes the systems engineering processes deployed on Morpheus, including the relationship 
to the technical aspects of the design, development, and testing. The intent is not to provide a condensed version of a 
Systems Engineering Management Plan (SEMP), but to describe the means by which key processes were executed. 
The subsequent section discusses attributes of “elegant design” on which Morpheus will be evaluated, and some of 
the specific technical challenges faced by the team. 


6. Systems Engineering Implementation on Morpheus 

Many times, processes are employed because they “always have been.” Some processes may serve as a “lowest 
common denominator” approach to systems engineering: they do not take into account the size, composition, 
dedication, personalities, capabilities, or knowledge base of a team. These kinds of standard processes may be 
needed for very large programs in which tailoring or consideration of engineers as individuals is not practical. The 
Morpheus team, however, had the opportunity to try processes and get immediate feedback from the engineers who 
used them. 

As for how to implement processes, there are many who advocate that good Systems Engineering can be “tool 
agnostic;” that is, it doesn’t matter what tool or suite of tools are used, as long as they serve the needs of the systems 
engineering functionality. It has been a lesson learned on Morpheus, however, that team members are more likely to 
use the tools and comply with processes if the tool usage is as appealing as possible. This concept is illustrated in 
Figure 6. Having a tool suite that is easily customized by the end user makes this even more likely. 
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Figure 6 - How to get the team to like SE&I 


When Morpheus was first initiated, the JSC Engineering Directorate offered the use of a Microsoft SharePoint 
site for project collaboration and document management. This was a relatively new innovation at JSC, and the 
Directorate was enthusiastic about having a project investigate ways to make use of it. The Directorate would 
provide site-level administrative support for setting up the basic site infrastructure, set up the initial team roster, and 
provide technical support for getting started. The rest was up to the project. 

The new SE&I team quickly took advantage of the opportunity to try it out and see if it could be used most 
effectively for project execution and systems engineering process implementation. The initial vision was to see if it 
could be used to replace and/or improve upon the use of a host of different tools that were utilized by the larger 
NASA projects and programs. The intent here is not to specifically advocate for the use of SharePoint, but to 
describe how this particular integrated collaboration environment was used to solve many problems encountered 
with other approaches, and how it became the backbone for most of the systems engineering and many of the project 
management functions. 
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The three key features of SharePoint that the Morpheus project uses heavily are: 

1 . Document repository (via “Shared Documents” folders) 

2. Web pages / wiki pages for organization and communication to the team, including meeting workspaces 

3. SharePoint “Lists” as databases for project data 

Most projects that have used SharePoint are familiar with the document repository features and the web pages. 

On the Morpheus SharePoint site, each subsystem has its own “sub-site” in which content can be managed however 
they wish. The main home tab and the SE&I tab contain most of the integrated content. However, the Morpheus 
team has found that the most powerful features have come from using lists. Lists have these attributes: 

• They are “Excel”-like in nature 

• The information is accessible by the entire team 

• The information in lists is the “authoritative source” - the team never needs to wonder whether the list is 
the latest version or not 

• Version history can be applied for each item in the database; any change is immediately marked with who 
made it, and when 

• Team members can subscribe to changes and receive automatic email updates instantly, daily, or less 
frequently 

• Each list, and each item, can be set for specific permissions for reading and modification 

• Team members can add information to the database collaboratively and simultaneously; there is no 
document that needs to be checked out and checked in 

• Every item has an “owner” assigned 

• Data can be cross-referenced between lists. For example the “Test Log” is linked to “Discrepancies” so that 
each flight test shows a record of discrepancies that occurred. Figure 7 shows an example of data 
relationships for SE&I products. In most projects, these products exist as separately maintained databases 
or documents. In SharePoint, items can easily be linked to each other so that data relationships can be 
viewed and maintained. 

• Views can be tailored to show only selected columns or filtered fields 

• The data entry record can include descriptive information to tell the user exactly what to fill in 

• No special programming skills are required for the team end users or site owners 

• Good for not knowing everything you’ll ever need at the start, because lists and fields are easy to add at any 
time 

• Can be implemented with as much or as little process rigor as appropriate 

• Easy to tailor and add or modify fields to suit the needs of the team 

• SharePoint has a close integration with Microsoft Visio, which can provide block-diagram style interactive 
drawings for websites that are dynamically linked with SharePoint list items 
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Figure 7 - Relationships between SE&I products 

The SharePoint site administration has been fairly low overhead for the team. The systems engineering team is 
trained on the basics of managing and updating lists, and there is only one individual who provides a basic 
administrative function to create and make updates to list at less than 5% of her time. Nearly all of the features used 
by the team are from out-of-the-box solutions, with no special programming or third party tools. 

The SharePoint site forms the basis for many of the collaborative tools, but the real effort for the team has been 
in deciding how much to employ each process, and it what manner. This goes back to the descriptions of rigor early 
on; for each SE process the team has to determine how to make it value-added. In addition to SharePoint lists, the 
team uses PowerPoint, Excel, and other software tools. The following paragraphs describe key aspects of the 
requirements, design, development and integration, integrated testing and verification, flight test operations, and 
other products over the lifecycle such as schedule, risks, and failure analyses. 

A. Requirements 

The requirements process started with the definition of Needs, Goals, and Objectives (NGOs). From these 
NGOs, a set of around a dozen Level 1 requirements were developed The NGOs and Level 1 requirements were 
approved in an informal System Requirements Review (SRR) by the customer at the time, who was the Engineering 
Directorate. In parallel, a draft concept of operations was created using a tried- and- true team collaboration approach 
of sticky notes on flip chart paper, spread out across the conference room table. 

Morpheus was then fortunate to have a top systems engineer on the project who had been working on 
Constellation Program requirements for the Altair lander vehicle. He brought a model-based systems engineering 
approach to the team for the development of Level 2 (system) requirements using the Cradle tool, which 
incorporated both the concept of operations (electronically) and the top level requirements. In seven weeks, the 
Morpheus team had a solid set of Level 2 requirements from which to proceed with the design. 

At one point, the SE&I team tried to mimic the Cradle block diagram-to data item interface by using MS Visio. 
Visio 2010 can be dynamically linked with SharePoint. The implementation worked well as a demonstration, but not 
many team members had Visio, and so it wasn’t sustainable from a collaboration perspective. 

After the initial draft of Level 2 requirements, the team switched over to using SharePoint as the requirements 
database. Although Cradle is a highly capable tool, there is a fairly steep learning curve, access requires licenses, 
and administrative support is also needed to customize or tailor the fool. The requirements are housed in a 
SharePoint list, not as an Excel or Word document stored in a SharePoint folder. 
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Some Level 2 requirements were flowed down to Level 3 (subsystems), but for the most part, subsystems were 
expected to generate the Level 3 requirements for their subsystems, and to define interface requirements. The project 
and the SE&I team’s approach was to not overdefme or overconstrain the end products, but to allow prototyping and 
testing to dictate much of the capability. Additionally, the team spent very little time “wordsmithing” the 
requirements because team members were present and interacted often enough to not need to write them in a way 
that led only to perfect interpretation. None of the requirements were being handed off to a contractor or 
subcontractor to bid against or implement. This is an important point, because much of the labor hours that a 
contracting organization typically spends on refining requirements is because of the fear (often well founded) that 
the contractor will not produce results envisioned, whether due to unintentional misinterpretation or by meeting the 
requirement just enough to satisfy the wording, in order to reduce cost. When the organization producing the 
requirement is the same as the organization producing the end product, fears are greatly minimized. 

During the design phase of the 1.5B vehicle, the original requirements list from the 1.5 A vehicle were scrubbed 
and revised based on what the team had learned over the previous year of testing. Many interface requirements were 
also added. 

The interfaces with ALHAT were defined in a SharePoint list as shown in Figure 8. This is a status view that was 
used to provide insight into the progress of interface (I/F) definition and also the threat associated with the interface. 
A partial list of the interfaces can be seen on the left side of the figure. Each data record contains more information 
than shown in this view, including the Morpheus responsibility and the ALHAT responsibility for each interface, 
plus a point of contact on each side. The color-coding is automatic based on the what is selected in the data record 
and gives the user a quick visual indicator of the status and threat associated with each item. Many of the items 
either include a more detailed interface control document (ICD) as an attachment, or have a hyperlink for the 
location of the detailed document where it is located in SharePoint. 
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Figure 8 - Morpheus/ALHAT interface definition status view 


B. Design 

The vehicle “quad” design and tank configuration design is based off the heritage experience with Armadillo’s 
“quad” design landers, and with the benefits of (a) low center of gravity for surface landings, and (b) a configuration 
designed to more easily enable a top-mounted payload. The team conducted a short trade study on the primary 
structure configuration and the tank- structure interface, and settled on an option that had a slightly higher weight but 
higher structural margin than the alternatives. The vehicle physical design is implemented and managed in Pro-E. 
Formal drawing approval processes have been implemented at various times during the project, but the key has been 
that the designers have enough expertise and a sense of responsibility to ensure that the right people have reviewed 
the drawings. If the drawing included welds, a welding expert would review. The project Chief Engineer reviewed 
almost every drawing. 

In addition to the Pro-E models, the vehicle subsystems and components are accounted for in the Master 
Equipment List (MEL), also in SharePoint. Initially the MEL was used in an Excel-like format to list each 
component and its expected mass properties, including weight growth allowance, which was typically set to between 
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10-30%. Component specification sheets, vendor data, and photos are also attached to the data records for individual 
items. Later in the project life cycle, the MEL was modified so that it could be used to track the as-built Morpheus 
vehicle configuration, by recording the as-measured vehicle weight, as well as a history of component serial 
numbers that are on the vehicle at any given time. The list, which can be exported to Excel, has about 45 data 
columns for each component and currently contains almost 1,100 components and sub-components. It is easy to sort 
by fields, and to view with only a subset of columns, such as a tailored view to just view items that are currently 
installed on the vehicle. 

Many of the non-structural vehicle and ground systems elements have heritage in the Armadillo implementation. 
The Morpheus team took delivery of the “1.0” vehicle from Armadillo, but replaced much of the avionics, the 
wiring, the GN&C sensors, and the main engine with JSC-developed components. The design process for the 
Morpheus 1.0 vehicle included multiple Design and Analysis Cycles (DACs). SharePoint provided an easy means 
by which team members could provide inputs electronically in a collaborative database for the equivalent of “Task 
Description Sheets” that had been used on Orion. Having the inputs in a common database allowed all subsystems to 
view and edit each other’s entries, and to easily sort or filter during team discussions. 

The project has had four major design reviews: two for the initial 1.0 vehicle configuration, one for 1.5 A, and 
after the 1.5 A vehicle crash, a “design upgrade review” was held to evaluate changes that would provide additional 
robustness and reliability. About 70 upgrades were approved as changes from the 1.5A vehicle to the 1.5B vehicle. 

For each design review, a template was provided to the subsystems to populate, and all materials were uploaded 
to a SharePoint meeting workspace. There is always a balance between having the team spend time creating new 
material and the need for technical documentation. The design reviews provide a good “forcing function” for 
capturing information that otherwise would likely not be recorded. 

For the design reviews, team members were encouraged to invite peer reviewers, and the project also extended 
invitations within the Engineering Directorate to other experts. Review Item Discrepancies (RIDs) were captured in 
a SharePoint list. The design reviews each typically lasted 2-3 days. Appendix G of NPR 7123 describes the 
recommended best practices for entrance and success criteria for technical reviews, and these were used as 
checklists for the design review content. In addition to the design reviews, the project held technical integration 
meetings to work specific technical issues at whatever frequency was required. 

In 2012, the GN&C team began heavily documenting the GN&C design using SharePoint “wiki” pages. The 
SharePoint wiki uses a similar infrastructure to the regular SharePoint web pages, but allows for the convenient wiki 
implementation shortcuts. 

C. Development and Subsystem Testing 

Subsystem leads are responsible for component and subsystem development up to the point of vehicle 
integration. In general, each subsystem applies best practices per their own organization’s discipline expectations. 
There are some exceptions during which the project will accept risk associate with lower factors of safety, reduced 
testing, or less margin, if it is consistent with the overall project risk posture. Subsystem leads are also responsible 
for identifying quality control measures, as appropriate. 

As the primary means for software simulation and analyses, the team selected the Johnson Space Center 
developed “Trick”simulation environment, in which the team could run the actual flight software within the 
simulation model. Trick models were developed to simulate individual hardware components and their interactions, 
along with environmental models to simulate forces encountered during free flight. Using this method, complete 
Morpheus flights are simulated within Trick, allowing the developers to test and tune their flight software at their 
desktop without the need for costly fight hardware and field-testing. 

Due to the rapid pace of the project, and the evolving requirements, the Flight Software Team adopted a spiral 
development approach based on NASA’s Software Development Requirements (NPR 7150.2A). The cFE/CFS 
system lends itself well to a spiral development flow, due to the ability to get up and running with a base system 
quickly, and the hardware independence of application development on top of CFS. Using the Redmine project 
management system (layered on top of the Subversion configuration management system) has allowed for 
distributed software development activities between organizations within JSC and also between NASA centers. 

For hardware components, the make/buy approach varied by subsystem and by component. Some highlights: 

• The 1 .5 A vehicle primary structure was cut and welded at Armadillo Aerospace. 

• The 1 .5B vehicle primary structure was cut and welded at a different vendor. The JSC structures team and 
welding experts evaluated weld samples prior to approving the start of welding; aluminum is notoriously 
difficult to weld. Welds were also x-rayed prior to delivery of the primary structure to JSC. Static load 
testing of the structure was performed at JSC. 
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• The top deck and accessory brackets were designed at JSC and built and welded either by vendors or by 
JSC’s machine shop. 

• The 1 .5 A propellant tanks were punch- formed at a vendor selected by Armadillo Aerospace. They were 
welded at Armadillo in stages, and in between stages were driven down to JSC for non-destructive 
evaluation (NDE), including dye penetrant, ultrasonic inspections, and weld x-rays. 

• The 1 .5B propellant tanks were spin- formed at one vendor, shipped to another vendor for machining to the 
correct thickness, and then to a third vendor for welding. Again, weld samples were evaluated prior to 
approval to begin welding. JSC team members made numerous site visits to the vendor to ensure that the 
processes were well understood and consistent with project expectations. The propellant tanks were 
qualification tested (cryogenic cycle testing and burst testing) at JSC. 

• The avionics and battery boxes were populated and assembled at JSC. 

• All of the GN&C sensors and antennas are off-the shelf but were rate-table or field tested. 

• The wiring harnesses were all built on site at JSC. A mockup of the vehicle top deck was developed in order 
for engineers to measure wiring harness lengths before cutting wire. 

• The propulsion feed system components were cut at JSC and welded in JSC’s welding shop. They were 
cleaned and pressure tested on site at JSC in the Energy Systems Test Area (ESTA). 

• The main engine was machined using external vendors but welded at JSC. The main engine design lead 
maintained a frequent presence in the machine shop to ensure communication with the welder. 

Vehicle tests are the primary method for verification of the integrated system performance. However, numerous 
subsystem tests are conducted where appropriate prior to acceptance or in response to integrated performance. For 
example, the team performed: 

• Main engine testing at Stennis Space Center, shown in Figure 9. 

• Propellant line cleaning and proof test at ESTA 

• Vehicle low pressure leak checks outside of the hangar 

• Instrumentation calibration 

- Load cells, Pressures, Temps, etc. 

— Channelization 

• Laser (Leica) scans of as-built vehicle 

• Tether/bungee characterization for tether tests 

• Card-level power and avionics tests 

• End-to-end gimbal pointing calibrations 

• Center of gravity (CG) measurement and balancing 

• Complete vehicle functional and procedure checkout prior to each flight 
test 

The systems engineering approach for subsystem development was to serve as an 
interface between subsystems and to also ensure that subsystems conducted testing 
prior to vehicle integration, and to allow subsystems to define how development and 

subsystem testing would be performed. The amount and scope of testing varied by 
subsystem, and SE&I worked with the them to capture the testing approach and 
follow up to ensure each test was completed. An example of the subsystem test flow 
from the propulsion subsystem is shown in Figure 10. 


Figure 9 - Main engine 
testing at Stennis Space 
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Figure 10 - Subset of propulsion subsystem test flow 


A detailed integration plan was defined for the vehicle, in order to manage dependencies with regard to what 
components needed to be integrated first. The “Assembly Databook” was posted and updated weekly in SharePoint. 
A sample from the assembly databook is shown in Figure 11. 
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D. Integrated Testing and Verification 

The team defined verification requirements for each project requirement at Level 1 and Level 2, and then 
identified test events or analyses that would be used for verification. Verification credit was sometimes taken for 
integrated tests, if the hardware and software was of a high enough fidelity. The primary approach for verification 
credit was through the initial field tests: dry run, wet run (with loaded liquid oxygen and liquid methane), and hot 
fire testing. 

The verification test list was managed in SharePoint for the 1.5A vehicle development. For 1.5B, the team used a 
combination of X-Mind maps and bum-down lists (typically in PowerPoint) to track and manage the tests and tasks 
leading up to them. 

All integrated tests and flight tests are recorded in the SharePoint test log, shown in Figure 12. Discrepancies are 
added to the Discrepancy List, and the two lists are linked together. A useful feature of both lists is that videos and 
photos can be added as test evidence or for later discrepancy resolution. 

Of all the SE products, the one that is most used and enforced is the discrepancy list. When discrepancies have 
been recurring, it has been invaluable to have thorough records of previous events and how they were addressed. 
Discrepancies that require mandatory closure for the next flight test are reviewed and closed out as required, but the 
project approach is that all open discrepancies must be closed or waived by the project before the first free flight. 
The discrepancies are statused at the free- flight Test Readiness Review (TRR). 
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Figure 12 - Morpheus test log in SharePoint 


E. Flight Test Operations 

The flight test objectives and test campaign for Morpheus 1.5B at JSC are shown in Figure 13. The same 
approach was used for the 1.5A vehicle. The test objectives have changed very little since vehicle integration was 
complete, but the number of tests and test sequencing has changed to meet the needs of the project. A set of test 
objectives and test campaign is also laid out for free flight testing at KSC leading up to the HDP trajectory. 
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JSC Flight Test Objectives 


1. Demonstrate HD4 engine performance on integrated vehicle with Morpheus 1 ,5b upgrades, characterize RCS over range of 
pressures and inlet conditions 

2. Characterize integrated HD4 and RCS performance 

3. Envelope launch environments and demonstrate vehicle operation for worst-case vibe, acoustics, heating , engine 
overpressure conditions, and debris 

4. Validate propulsion simulation models 


5. GN&C 6 DOF stability and control for ascent, hover, and descent for integrated vehicle with Morpheus 1 ,5b upgrades 

6. Tune guidance and control for free flight stability and performance 

7. Characterize Backup-IMU performance during tether test 

8. Demonstrate transition to the Backup-IMU for Soft- Abort 

9. Demonstrate transition to the Backup- Roll Control for Soft-Abort 

1 0. Integrated test of launch and landing from ground (tethered for range safety) alhat Sensors 

11. Demonstrateciosed-loopvehicte control during hover with active ALHAT sensors 

12. Full HDP duration flightiest before free flight 


Figure 13 - Morpheus 1.5B flight test objectives and JSC test campaign 
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Figure 14 shows an example set of test objectives for the initial hot fire test. The color coding was used to show 
which objectives were met (in green), which were partially met (in orange), and which were not tested yet or failed 
testing (in red). This helped the team to plan objectives for the upcoming tests. 


Icpnilcr Tcitinqi 



Hot- fire 


Figure 14 - Hot fire test objectives 


Flight testing includes hazardous operations, with hazards that include pressure systems, cryogenic fluids, noise, 
extreme heat, and lift operations. The team maintains a list of hazards in SharePoint, including an analysis and 
identification of controls for each hazard. An engineer from JSC’s Safety and Mission Assurance (S&MA) 
organization is embedded in Morpheus in order to be highly knowledgeable about the team and test operations. 

Flight test procedures were originally managed in SharePoint, and modified for each test. JSC’s Mission 
Operation Directorate (MOD) made an electronic procedures tool available to the team, and that has been in use for 
the 1.5B vehicle test campaign. Flight rules and launch commit criteria are maintained in a SharePoint list. The team 
reviews these at flight operations tagups as changes are proposed. 

Each new flight test configuration is preceded by an internal team Test Readiness Review. The internal TRR is 
typically chaired by the project manager and hosted by SE&I. The TRR sign-off uses the “formal approvals” list in 
SharePoint, in which each responsible party can go into SharePoint and change the status from “not signed” to 
“signed.” Because SharePoint keeps a record of all changes, the entry is automatically time stamped with the user’s 
name. 

A data review is held two to three days after each flight test. A folder is created in SharePoint for each flight test, 
and the team uploads the post-processed data plots, as-run procedures, and any presentations or files to explain test 
results. The SE&I team also manages a SharePoint list of key test parameters to be able to easily compare flight-to- 
flight performance. 
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F. Schedule 

Depending on where we have been in the project life cycle, the schedule has been managed in MS Project, or 
using PowerPoint calendar, or using whiteboard in the hangar. When using MS Project, we typically have a 
“schedule lead” within the SE&I team who solicits inputs from the subsystem leads and works with them to update 
durations and end dates. We have found that having an engineer manage the schedule is more effective than having 
a non-technical scheduler, because the engineer understands enough to extract critical information from the team 
members, and also benefits from better understanding the technical status. MS Project has been particularly valuable 
earlier in the project life cycle for managing task dependencies and planning for major milestones. PowerPoint 
calendars and whiteboards are more effective later in the lifecycle when the team is more co-located in the hangar on 
a daily basis. 

G. Risks 

Risks are managed informally on the project, with constant involvement by management team. The SE&I team 
always maintains a list of project risks, and brings them forward to review and discuss at the MRCB or near major 
milestones. The SE&I team constantly polls the subsystem leads for risks and concerns and then takes steps to 
address them. The risks are put into a standard 5x5 risk matrix for presentation to external audiences. 


H. Failure Analyses 

The SE&I team has generated fault trees for major project failures and events. An example is shown in Figure 
15. The fault tree serves as a way to organize the failure investigation. A similar fault tree was created following the 
crash of Free Flight 2. That investigation was followed with a set of corrective actions that were addressed during 
the Morpheus 1.5B lifecycle. 


□ 

□ 



Figure 15 - Preliminary fault tree for Morpheus 1.5B soft aborts due to lateral excursion 
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7. Elements of Elegant Design on Morpheus 


Elements of elegant design for Morpheus cannot be fully assessed until after the project completes the full HDP- 
duration free flight testing with ALHAT. This section defines a list of qualities on which to assess elegant design, 
consistent with the definitions and examples in Griffin’s paper. 

A. Does it work? 

o Ultimate objective: were we able to fly a 1-km class slant range approach to a hazard field and have 
ALHAT select and guide the vehicle to land safely at an acceptable landing site? 
o Intermediate objectives: 

■ Does the LOX/methane propulsion system work? 

■ Can the vehicle perform a stable hover and vertical/lateral maneuvers under tethered flight? 

B. Is it robust? 

o Does the engine have good combustion stability under a reasonable start box of propellant 
temperatures and pressures? 

o Do the methane RCS engines have good performance under a range of high or low usage conditions 
over the flight time? 

o Does the vehicle perform as required under the full range of outdoor weather conditions (temperature, 
humidity, winds)? 

o Does the control system response to small changes in engine axis of thrust relative to c.g.? (structural 
deflection of engine gimbal, c.g. motion due to propellant shift) 
o Does the vehicle remain stable and controlled in the presence of wind gusts? 

o Does the vehicle structure and landing gear integrity remain sound after off-nominal landings? 

o Does the navigation system handle structural deflection of the navigation base due to loads? 

o Does the vehicle proceed along its trajectory with reasonable deviations in the presence of corrections 

to attitude control? (since lateral y-z motion control is coupled with pitch and yaw control) 
o Do the vehicle electrical systems remain performing as expected in the presence of induced or external 
EMI and RFI? 

o Does the navigation solution remain stable in the presence of spurious navigation sensor inputs? 
o Does the propellant feed system remain performing as needed to support main engine performance in 
the presence of vehicle attitude-induced propellant imbalance between tanks? 

C. Efficient 

o Were the manufacturing / fabrication approaches effective and did they produce quality results? 
o Does the propulsion system have a good Isp and mass fraction relative to alternate options? 
o Do the pre-flight test day operations make effective use of team members’ time? 
o Is the turnaround time reasonable between flights in terms of maintenance and sustaining engineering? 
o Are the consumables used efficiently with minimal waste? (GN2, LN2, LNG, LOX, Helium) 
o Are the vehicle and ground power consumption managed efficiently during the test day? 

D. Have we minimized unintended consequences? 

o What is the evidence that integrated effects were considered for the system operation in its 
environment? 

o What was the frequency and consequence of unintended consequences and how were they managed? 
The project has handled several technical integration and operational issues. Examples are provided in Table 1. 
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Table 1 . Morpheus technical issues 


Issue 

Impact 

Vehicle mass growth - heavy tanks 
which are more robust; small 
amounts of mass used to solve many 
technical challenges (brackets, 
vibration isolation, etc) 

Reduced flight time for the HDP trajectory; team has higher need for higher 
thrust engine, so continuing to build and test the more powerful “HD5” main 
engine 

Grounding and electrical isolation 
issues 

The team has taken time to improve electrical isolation of wiring and 
components and reduce effects 

Main engine combustion stability 

An instability detection system was added to the vehicle; multiple tests were 
performed to identify stable start conditions 

Heating and humidity impacts on 
electronics when testing outside in 
ambient conditions 

A gaseous nitrogen purge is used for the vehicle avionics and many of the 
ALHAT components during all outdoor ground operations; active cooling is 
also provided for the vehicle avionics, using liquid nitrogen through a cold 
plate for ground testing, and liquid methane during flight. ALHAT flash 
lidar has humidity constraints for the imager. 

Propellant imbalance between tanks 

An imbalance between tanks creates an offset in the center of gravity that 
creates an initial horizontal motion. For tether testing, the team has spent 
time coming up with vehicle leveling techniques, and the guidance and 
control gains have been adjusted to quickly recover from the initial 
imbalance. 

Propellant conditioning for main 
engine and methane RCS 

The main engine needs to start with relatively warm methane, while the 
methane RCS performs better with colder methane. The original design for 
cooling the avionics would also chill the main engine methane lines too 
much, so that was modified to be independent. The team discovered through 
testing that the methane RCS could start with warm methane and quickly 
improve performance as the methane lines chilled in. 


8. SE&I Lessons Learned 


In reviewing the systems engineering approach for Morpheus, the following qualities have been identified on 
which to consider the effectiveness of an SE&I team: 

End product: 

It works 
It is robust 

It is efficient compared to alternatives 
Unintended consequences have been minimized 
Requirements: 

The project knows what the customer wants 

The project knows the constraints and external interfaces with which it must comply 
The team knows what needs to be done to provide what the customer wants 
Interface requirements are defined and managed 

Design: 

Trade studies consider relevant factors and their relative importance 
Complexity is eliminated as much as possible 

Technical decisions consider the project’s cost and schedule constraints 
Records: 

The design is documented well enough to be understood and referenced by the team and external reviewers 
The design is documented well enough to be reproducible 

Notes, actions, and decisions are captured and disseminated to the team accurately and in a timely manner 
Changes: 

Are tracked and managed appropriately 
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Unintended consequences are considered before the changes are allowed 
Proposed changes consider impacts of all subsystems affected by the change 

Processes: 

Are employed during the appropriate parts of the project lifecycle 

Use an appropriate amount of rigor for the scope of the project 

Use tools that are accessible by the team, and do not have a high learning curve 

Employ specialized systems engineering tools when needed (such as fault trees) 

Subsystems understand the value of the levied processes 
Subsystems comply with the required processes, when required 
Team members do not mutiny due to SE&I “overhead” 

Have management buy-in and advocacy 

SE&I team: 

SE&I team has enough resident expertise to understand and challenge all aspects of the requirements, 
design, development, testing, operations, and sustaining engineering 
Is perceived as value-added for helping the team to be successful 
Is proactive, not just reactive 

Is able to identify, communicate, and manage complex technical problems 
Facilitates communication, integration, and conflict resolution among team members 
Is not afraid of challenging team members when appropriate, but is always respectful and courteous 
Is good at listening 

Risks: 

Are identified and managed 

In addition, there are a number of systems engineering lessons learned so far on Morpheus: 

• Every team is made up of people who believe in more or less process rigor depending on their experiences and 
work style 

• Every team is made up of people who have an expectation of risk tolerance or risk aversion, and the project 
management team needs to constantly set the bar for how much risk will be accepted 

• Having an in-house team greatly reduces the time needed for writing and managing requirements, because 
internal communication is easy and with low likelihood of other agendas 

• Subsystems want to ensure their own subsystem success first, and will stay head down unless they are required 
to integrate; most subsystems won’t “seek” integration unless it’s for their own subsystem’s benefit 

• For SE&I processes, demonstrating value and getting buy-in from the team makes it more likely they will 
comply 

• Having a good tool / environment helps the team to be willing to comply with processes 

• SE&I should function as a service organization and help with team integration, but technical leads must also 
support integration, especially when the SE&I team is very small 

• Fabrication or manufacturing at external vendor requires many site visits and regular tagups in order to get the 
product that is needed 

• Management has to be an active advocate of the SE&I strategy or the team will not execute it 

• Not all systems engineering tools and processes are needed over the whole lifecycle 

• Knowing the team well is valuable, in order to know who will comply with requests and who will need to be 
coerced to comply 

• With less documentation, the team has to rely heavily on low turnover and high team member engagement in 
the project 

• The team integrates more naturally when the team members know each other well, trust each other, and are 
more like family. One way to help integrate the team is to create a fun work environment with food, team 
lunches, happy hours, seasonal parties and celebrations. Social activities break down barriers to communication, 
and encourage recognition that the team is also working toward the same end goal. 


23 

American Institute of Aeronautics and Astronautics: SPACE 2013 



9. Summary and Conclusions 


Morpheus has provided a means for NASA to evaluate innovative ways to tailor the systems engineering 
processes for a complex in-house terrestrial flight test project. The team considered scalability when selecting 
approaches, and it is believed that many of them can be scaled up to create leaner processes for larger projects and 
programs. SharePoint turned out to form a very effective collaborative tool for managing the team’s data and 
information. 

In addition to developing lean processes, the Morpheus SE&I team gained greater insight into the need for 
technical depth and breadth across the SE&I team. This type of project provides critical experience and skills for 
NASA engineers. 
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